Test Pyramid

Martin Fowler

参考

TestPyramid

2012

https://gyazo.com/f406fd15f04251b8a1a24077f2fc06c2

この図の通り、Unit testの比率を上げようぜというもの

UIのtest(E2E)は問題がある

テストが脆く、壊れやすい

時間がかかる

build時間がかかる

自動化用のsoftwareのライセンスが必要

この当時はSeleniumとかSahiとかの時代

↓の記事を読んだ感じ、2012年より前は、UIのテストを重んじるノリがあったらしい

So the pyramid argues that you should do much more automated testing through unit tests than you should through traditional GUI based testing. ref

I always argue that high-level tests are there as a second line of test defense. If you get a failure in a high level test, not just do you have a bug in your functional code, you also have a missing or incorrect unit test. Thus I advise that before fixing a bug exposed by a high level test, you should replicate the bug with a unit test. Then the unit test ensures the bug stays dead.

上レイヤーのテストが失敗したら、単体レベルでもテストが欠落しているということを意味する

上レイヤーのテストを治す前に、単体テストを修正すべき

その後、Test Pyramidに対するアンチテーゼが出てきた

Testing TrophyやTesting Honeycomb

これらはunit testの比率を下げて、Integration testの比率を上げようという主張

それに対する2021のMartin Fowlerの記事

On the Diverse And Fantastical Shapes of Testing

その辺の議論は、UnitとIntegrationの線引がかなり不明瞭だと指摘

そうだねmrsekut.icon

Testの分類が不明瞭

Fowlerは、Unit testを2つに分類している

https://gyazo.com/9758b661ab62f872033cd3a6f8ae0bfc